Supporting transport diversity and time-shifted buffers for media streaming over a network

ABSTRACT

A device for processing media data includes one or more processors configured to receive a session description protocol (SDP) message including an attribute that defines a time-shifted buffer (TSB) depth, determine an amount of memory for the TSB based on a value of the attribute, allocate the determined amount of memory to the TSB, and store at least a portion of media data associated with the SDP message in the TSB. The value for the attribute may signal the depth of the TSB in terms of playback time in seconds. The attribute may leverage the extensibility of SDP messages through, for instance, “a=” lines. For instance, the TSB depth attribute may correspond to an “a=tsb-length:” attribute.

This application claims the benefit of U.S. Provisional Application Ser.No. 61/752,456, filed Jan. 15, 2013, and U.S. Provisional ApplicationSer. No. 61/809,871 filed Apr. 8, 2013, the entire contents of each ofwhich are hereby incorporated by reference.

TECHNICAL FIELD

This disclosure relate to communication systems, and more particularly,to delivery of content via a network.

BACKGROUND

Digital video capabilities can be incorporated into a wide range ofdevices, including digital televisions, digital direct broadcastsystems, wireless broadcast systems, personal digital assistants (PDAs),laptop or desktop computers, digital cameras, digital recording devices,digital media players, video gaming devices, video game consoles,cellular or satellite radio telephones, video teleconferencing devices,and the like. Digital video devices implement video compressiontechniques, such as those described in the standards defined by MPEG-2,MPEG-4, ITU-T H.263 or ITU-T H.264/MPEG-4, Part 10, Advanced VideoCoding (AVC), and extensions of such standards, to transmit and receivedigital video information more efficiently.

Video compression techniques perform spatial prediction and/or temporalprediction to reduce or remove redundancy inherent in video sequences.For block-based video coding, a video frame or slice may be partitionedinto blocks. Each block can be further partitioned. Blocks in anintra-coded (I) frame or slice are encoded using spatial prediction withrespect to neighboring blocks. Blocks in an inter-coded (P or B) frameor slice may use spatial prediction with respect to neighboring blocksin the same frame or slice or temporal prediction with respect to otherreference frames.

After video data has been encoded, the video data may be packetized fortransmission or storage. The video data may be assembled into a videofile conforming to any of a variety of standards, such as theInternational Organization for Standardization (ISO) base media fileformat and extensions thereof, such as AVC.

Wireless communication networks are widely deployed to provide variouscommunication services such as voice, video, packet data, messaging,broadcast, etc. These wireless networks may be multiple-access networkscapable of supporting multiple users by sharing the available networkresources. Examples of such multiple-access networks include CodeDivision Multiple Access (CDMA) networks, Time Division Multiple Access(TDMA) networks, Frequency Division Multiple Access (FDMA) networks,Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA)networks.

The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE)represents a major advance in cellular technology as an evolution ofGlobal System for Mobile communications (GSM) and Universal MobileTelecommunications System (UMTS). The LTE physical layer (PHY) providesa highly efficient way to convey both data and control informationbetween base stations, such as an evolved Node Bs (eNBs), and mobiledevices, such as UEs. In prior applications, a method for facilitatinghigh bandwidth communication for multimedia has been single frequencynetwork (SFN) operation. SFNs utilize radio transmitters, such as, forexample, eNBs, to communicate with subscriber UEs. In unicast operation,each eNB is controlled so as to transmit signals carrying informationdirected to one or more particular subscriber UEs. The specificity ofunicast signaling enables person-to-person services such as, forexample, voice calling, text messaging, or video calling.

SUMMARY

In general, this disclosure describes techniques for streaming mediadata over a network. For example, this disclosure describes techniquesfor receiving media data via various types of transports, e.g., any ofunicast, broadcast, and/or multicast. For instance, a redirector/proxyunit may cause a streaming client to retrieve media data from theInternet directly via unicast, or when a broadcast or multicast serviceis available, from a broadcast or multicast middleware unit.Alternatively, the redirector/proxy unit may retrieve the media data onbehalf of the streaming client when the broadcast or multicast serviceis not available.

This disclosure also describes techniques related to buffering retrievedmedia data. For instance, retrieved media data may be stored in atime-shifted buffer (TSB). This disclosure describes techniques forsignaling a size of the TSB, e.g., in terms of playback time for themedia content, such that an appropriate amount of memory can beallocated for the TSB. In this manner, the media data can be played backat a later time and/or played back using a trick mode, e.g., fastforward or rewind.

In one example, a method of retrieving media data includes, by a proxyunit: obtaining mapping information that maps an identifier for mediadata to a resource location based on a service for retrieving the mediadata, wherein the service defines a type of transport for transportingthe media data, receiving a request for the media data from a streamingclient, determining whether the service is available, and, when theservice is available, causing the streaming client to receive the mediadata from a unit that receives the media data using the service from theresource location, based on the mapping information.

In another example, a device for retrieving media data includes a proxyunit configured to obtain mapping information that maps an identifierfor media data to a resource location based on a service for retrievingthe media data, wherein the service defines a type of transport fortransporting the media data, receive a request for the media data from astreaming client, determine whether the service is available, and, whenthe service is available, cause the streaming client to receive themedia data from a unit that receives the media data using the servicefrom the resource location, based on the mapping information.

In another example, a device for retrieving media data includes meansfor obtaining mapping information that maps an identifier for media datato a resource location based on a service for retrieving the media data,wherein the service defines a type of transport for transporting themedia data, means for receiving a request for the media data from astreaming client, means for determining whether the service isavailable, and means for causing, when the service is available, thestreaming client to receive the media data from a unit that receives themedia data using the service from the resource location, based on themapping information.

In another example, a computer-readable storage medium has storedthereon instructions that, when executed, cause a processor to obtainmapping information that maps an identifier for media data to a resourcelocation based on a service for retrieving the media data, wherein theservice defines a type of transport for transporting the media data,receive a request for the media data from a streaming client, determinewhether the service is available, and cause, when the service isavailable, the streaming client to receive the media data from a unitthat receives the media data using the service from the resourcelocation, based on the mapping information.

In another example, a method of processing media data includes receivinga session description protocol (SDP) message including an attribute thatdefines a time-shifted buffer (TSB) depth, determining an amount ofmemory for the TSB based on a value of the attribute, allocating thedetermined amount of memory to the TSB, and storing at least a portionof media data associated with the SDP message in the TSB.

In another example, a device for processing media data includes one ormore processors configured to receive a session description protocol(SDP) message including an attribute that defines a time-shifted buffer(TSB) depth, determine an amount of memory for the TSB based on a valueof the attribute, allocate the determined amount of memory to the TSB,and store at least a portion of media data associated with the SDPmessage in the TSB.

In another example, a device for processing media data includes meansfor receiving a session description protocol (SDP) message including anattribute that defines a time-shifted buffer (TSB) depth, means fordetermining an amount of memory for the TSB based on a value of theattribute, means for allocating the determined amount of memory to theTSB, and means for storing at least a portion of media data associatedwith the SDP message in the TSB.

In another example, a computer-readable storage medium having storedthereon instructions that, when executed, cause a processor to receive asession description protocol (SDP) message including an attribute thatdefines a time-shifted buffer (TSB) depth, determine an amount of memoryfor the TSB based on a value of the attribute, allocate the determinedamount of memory to the TSB, and store at least a portion of media dataassociated with the SDP message in the TSB.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example system for supporting transport diversity.

FIGS. 2A-2B illustrate alternative examples of apparatus including are-director/proxy for supporting transport diversity.

FIG. 3 illustrates aspects of an example process flow using are-director/proxy configured for re-direction operation.

FIG. 4 illustrates aspects of a method using a re-director/proxyconfigured for proxy operation.

FIG. 5 illustrates examples of a methodology for supporting transportdiversity.

FIG. 6 illustrates an example apparatus for implementing the methodologyof FIG. 5.

FIGS. 7 and 8 illustrate further aspects for supporting transportdiversity.

FIGS. 9 and 10 are block diagrams illustrating example multicastservices device client (MSDC) architectures for supporting Real-TimeTransport Protocol (RTP)/Real-Time Streaming Protocol (RTSP) streaming.

FIG. 11 is a conceptual diagram illustrating an example evolved MBMS(eMBMS) user service description (USD) schema snippet.

FIGS. 12 and 13 are block diagrams illustrating example components forsupporting transport diversity for an RTSP/RTP client.

FIGS. 14A and 14B are conceptual diagrams illustrating an exampleextensible markup language (XML) content model for extending a USD tocarry dynamic adaptive streaming over HTTP (DASH) Transport information.

FIG. 15 is a conceptual diagram illustrating an example architecture forsupporting DASH over MBMS.

FIG. 16 is a flow diagram illustrating a call-flow associated with thenetwork architecture of FIG. 15 for DASH content delivery over broadcastand unicast transport.

FIG. 17 is a conceptual diagram illustrating another examplearchitecture for supporting DASH over MBMS.

FIGS. 18-23 are flow diagrams illustrating various example call-flowsassociated with the network architecture of FIG. 17 for DASH contentdelivery over broadcast and unicast transport.

FIG. 24 is a flowchart illustrating an example method for signaling datarelated to a time-shifted buffer (TSB) depth in accordance with thetechniques of this disclosure.

DETAILED DESCRIPTION

In general, this disclosure describes techniques for supporting varioustypes of transport mechanisms for streaming media data, such as audioand/or video data, through a network. For example, an applicationservice client (which may also be referred to as a streaming client) maybe configured to interact with a proxy unit to retrieve media dataeither according to a unicast protocol or a broadcast (or multicast)protocol. In some examples, the proxy unit may determine whether themedia data can be retrieved using the broadcast protocol, e.g., based onwhether a client device is within an area of coverage of a serviceprovider for delivering media data using the broadcast protocol, andselect either the unicast protocol or the broadcast protocol based onwhether the client device is within the area of coverage. The clientdevice may execute the application service client and/or include theproxy unit. In some examples, the client device may execute theapplication service client, and the proxy unit may be included in adevice separate from the client device.

The techniques of this disclosure may be used in conjunction withvarious application-layer protocols for streaming media data. Forexample, the techniques of this disclosure may be used in conjunctionwith Dynamic Adaptive Streaming over HTTP (DASH), which utilizes HTTP tostream media data. As another example, the techniques of this disclosuremay be used in conjunction with Real-time Transport Protocol (RTP) orReal-Time Streaming Protocol (RTSP). In these and other instances, anapplication service client (e.g., an RTP client, an RTSP client, or aDASH client) may be transport-agnostic, in the sense that theapplication service client need not be aware of a transport mechanismused to retrieve media data. For instance, the application serviceclient need not be aware of whether an underlying transport mechanismcorresponds to a unicast protocol or a broadcast or multicast protocol.

As discussed in greater detail below, the proxy unit (which may also bereferred to as a redirector/proxy unit) may be configured to receive arequest from an application service client, where the request specifiescertain media data. The proxy unit may determine whether the media datacan be retrieved using a particular transport mechanism, e.g., abroadcast protocol or a unicast protocol. The proxy unit may then causethe application service client to receive the media data using one ofthe transport mechanisms (based on availability, preference,reliability, and/or other factors). For example, if the broadcastprotocol is more preferable than the unicast protocol, and the broadcastprotocol is available, the proxy unit may cause the application serviceclient to receive the media data via the broadcast protocol, whereas ifthe broadcast protocol is not available, the proxy unit may cause theapplication service client to receive the media data via the unicastprotocol.

As one example, with respect to DASH, media data may be available fromone or more servers, e.g., a broadcast server and a unicast server, as abroadcast and/or a unicast service. A DASH client may receive a modifiedmedia presentation description (MPD) for the media data that indicatesthat the media data is available from a proxy unit (rather than theserver(s)). When the DASH client sends a request for media data to theproxy unit, the proxy unit may determine whether a unicast protocol or abroadcast protocol is available for retrieving the requested media data.If the broadcast protocol is available, a broadcast receiving unit(e.g., a multimedia broadcast multicast services (MBMS) or evolved MBMS(eMBMS) middleware unit) may receive the media data, and the proxy unitmay cause the DASH client to send a request for the media data to thebroadcast receiving unit. On the other hand, if the broadcast protocolis not available, the proxy unit may cause the DASH client to send arequest for the media data to a unicast server, to retrieve the mediadata using unicast. Alternatively, the proxy unit may retrieve the mediadata from the unicast server, and then provide the retrieved media datato the DASH client. In some examples, the unicast server and thebroadcast server may correspond to the same server.

As another example, with respect to RTP or RTSP, an RTP client (which,alternatively, may correspond to an RTSP client) may submit DESCRIBE,SETUP, and PLAY commands to a proxy unit. In response to the DESCRIBEcommand, the proxy unit may provide a modified session descriptionprotocol (SDP) message to the RTP client. The modified SDP message mayspecify an address of the proxy unit as the address from which the mediadata is available. This modified SDP message may cause the RTP client tosend the SETUP and PLAY commands to the proxy unit. When the proxy unitdetermines that the broadcast protocol is available, the proxy unit maysend SETUP and PLAY commands to a broadcast receiving unit (e.g., anMBMS or eMBMS middleware unit), which may receive the media data andforward the media data to the RTP client. On the other hand, when theproxy unit determines that the broadcast protocol is not available, theproxy unit may retrieve the media data from a unicast server, and thenprovide the retrieved media data to the RTP client.

In some examples, components for performing the techniques of thisdisclosure may include an application service client, a proxy unit, anda broadcast receiving unit. In various examples, a client device mayinclude any or all of these components, alone or in any combination.Alternatively, the client device may include the application serviceclient, and the proxy unit and/or the broadcast receiving unit may beincluded in one or more devices that are separate from the clientdevice.

Moreover, this disclosure also describes techniques related to signalingdata for a time-shifted buffer (TSB). A client device (also referred toherein as “user equipment”) may allocate memory to form a TSB to be usedfor holding media data in support of various trick modes, such as fastforward, rewind, replay, or the like. In general, a trick mode may referto a playback mode in which media data is played back in an order orrate other than a defined output order. For instance, in fast forward,certain media data may be skipped. As another example, in rewind, anoutput order for media data may be inverted, and certain media data mayalso be skipped. To skip media data, e.g., with respect to video data,only pictures coded using an intra-coding mode could be displayed,skipping inter-coded pictures.

In accordance with the techniques of this disclosure, data may besignaled in, e.g., an SDP message, for instantiating a TSB. For example,a TSB attribute may be signaled, with a value defining, in seconds, anamount of media data that can be stored in the TSB. A client device maycalculate an amount of memory needed for the TSB based on the value ofthe TSB attribute. This calculation may involve, for video data as anexample, a frame rate of video data in the media data. The client devicemay calculate a memory size for the TSB based on an average amount ofdata per picture, a number of pictures in a period of time (based onframe rate), and a length of time as defined by the TSB attribute.Likewise, the client device may further determine an amount of memoryneeded for audio data, text data, or other data or media for the periodof time. Thus, the client device may allocate this data to the TSB forstoring media data to perform trick modes. Furthermore, the clientdevice may perform trick modes for data received via a broadcastprotocol, such as MBMS or eMBMS.

In other words, in some examples, the techniques of this disclosureinclude a middleware architecture for supporting features of Real-timeProtocol/Real-time Streaming Protocol (RTP/RTSP) streaming over evolvedMultimedia Broadcast Multicast Service (eMBMS) network. These featuresinclude time-shifted buffer and transport diversity (e.g., unicast tobroadcast switching or vice-versa for content delivery). For thetime-shifted buffer (TSB) feature, the architecture may supportextensions of the session description protocol (SDP) to include datasignaling a buffer depth. As one example of the transport diversityfeature, this disclosure describes proposes an architecture whereapplications consuming the content need not be aware of the details oftransport switching from unicast to broadcast or vice-versa, as thisswitching may be managed in the middleware level.

In HTTP streaming, frequently used operations include GET and partialGET. The GET operation requests the retrieval of a whole file associatedwith a given uniform resource identifier (URI) (e.g., URL or URN). Thepartial GET operation requests the retrieval of a byte range (subset) ofa resource. Thus, movie fragments may be provided for HTTP streaming,because a GET or partial GET operation can retrieve one or moreindividual movie fragments. In a movie fragment, there can be severaltrack fragments of different tracks. In HTTP streaming, a mediapresentation may be a structured collection of data that is accessibleto the client. The client may request and download media datainformation to present a streaming service to a user.

In the example of streaming DASH data using HTTP, there may be multiplerepresentations for video and/or audio data of multimedia content. Themanifest of such representations may be defined in a Media PresentationDescription (MPD) data structure. A media presentation may correspond toa structured collection of data that is accessible to an HTTP streamingclient device. The HTTP streaming client device may request and downloadmedia data information to present a streaming service to a user of theclient device. A media presentation may be described in the MPD datastructure, which may include dynamic updates of the MPD.

A media representation may contain a sequence of one or more periods.Periods may be defined by a Period element in the MPD. Each period mayhave an attribute start in the MPD. The MPD may include a startattribute and an availablityStartTime attribute for each period. Forlive services, the sum of the start attribute of the period and the MPDattribute availableStartTime may specify the availability time of theperiod in UTC format, in particular the first Media Segment of eachrepresentation in the corresponding period. For on-demand services, thestart attribute of the first period may be 0. For any other period, thestart attribute may specify a time offset between the start time of thecorresponding Period relative to the start time of the first Period.Each period may extend until the start of the next Period, or until theend of the media presentation in the case of the last period. Periodstart times may be precise. They may reflect the actual timing resultingfrom playing the media of all prior periods.

Each period may contain one or more representations for the same mediacontent. A representation may be one of a number of alternative encodedversions of audio, video or other data. The representations may differby encoding types, e.g., by bitrate, resolution, and/or codec for videodata and bitrate, language, and/or codec for audio data. The termrepresentation may be used to refer to a section of encoded audio orvideo data or other media or data corresponding to a particular periodof the multimedia content and encoded in a particular way.

Representations of a particular period may be assigned to a groupindicated by a group attribute in the MPD. Representations in the samegroup are generally considered alternatives to each other. For example,each representation of video data for a particular period may beassigned to the same group, such that any of the representations may beselected for decoding to display video data of the multimedia contentfor the corresponding period. The media content within one period may berepresented by either one representation from group 0, if present, orthe combination of at most one representation from each non-zero group,in some examples. Timing data for each representation of a period may beexpressed relative to the start time of the period.

A representation may include one or more segments. Each representationmay include an initialization segment, or each segment of arepresentation may be self-initializing. When present, theinitialization segment may contain initialization information foraccessing the representation. In general, the initialization segmentdoes not contain media data. A segment may be uniquely referenced usingan identifier, such as a uniform resource identifier (URI) (e.g.,uniform resource locator (URL) or uniform resource name (URN)). The MPDmay provide the identifiers for each segment. In some examples, the MPDmay also provide byte ranges in the form of a range attribute, which maycorrespond to the data for a continuous byte range of segment within aresource (e.g., file) accessible by referencing the corresponding URI.

Each representation may also include one or more media components, whereeach media component may correspond to an encoded version of oneindividual media type, such as audio, video, or timed text (e.g., forclosed captioning). Media components may be time-continuous acrossboundaries of consecutive media segments within one representation.

The techniques described herein may be used for the wireless networksand radio technologies mentioned above as well as other wirelessnetworks and radio technologies. For clarity, certain aspects of thetechniques are described below for LTE, and LTE terminology is used inmuch of the description below.

RTP/RTSP streaming is a common protocol for supporting real-timestreaming services. The 3GPP specification for eMBMS services describesthe architecture for RTP streaming over Long Term Evolution (LTE)networks. However, this disclosure, recognizes two problems withRTP/RTSP, and discusses techniques that may be used to overcome theseproblems.

The Time-shifted buffer (TSB) is a feature that may be used to store aportion of media content in User Equipment (UE). The buffer allows usersto move the playback point of media content forward or backward. In thisprocess, the UE needs to have been informed of the buffer depth, whichprovides an indication of how much time worth of content the UE needs toaccumulate at the device to allow for trick mode playback, e.g.,fast-forward and rewind of playback. In one implementation of a VLCmedia player, the TSB feature is enabled by providing the buffer depthas an argument to the VLC player at startup. The process is notautomatic, and instead requires intervention of a user to provide thebuffer depth argument and consequently enable the TSB. This disclosuredescribes techniques for supporting a TSB in an eMBMS-enabled middlewarelayer, such as a multicast services device client (MSDC).

The session description protocol (SDP) describes endpoint information ofa streaming service and its media stream (session) related parameters,collectively known as a “session profile.” Therefore, if a streamingservice is available in different transport methods, multiple profilesthat describe different transport/endpoint parameters for the serviceare needed. For example, a broadcast real-time RTP-based service canrefer to a multicast IP address and port for its media streams, whereasthe unicast version of the service may refer to a unicast IP address andport. There may be different representations of the media streams forbroadcast and unicast delivery methods. In LTE networks, the MSDCprovides delivery of streaming services to eMBMS-enabled applications.To support switching between unicast and other (e.g., broadcast ormulticast) transport methods, it needs to utilize multiple sessionprofiles, the choice of which will be based mainly on whether a UE isout of coverage or in coverage of broadcast. Whenever a UE moves tobroadcast coverage area, the MSDC may use the broadcast-enabled versionof the SDP profile to set up a connection and consume content. However,in the reverse scenario, when a UE moves out of broadcast coverage, MSDCmay need to use the unicast SDP and set up a unicast connection with theremote RTSP server to consume unicast content. To keep the transitionsbetween unicast and broadcast hidden from users or applications, thisdisclosure describes a mechanism for seamless transition.

This disclosure describes, among other techniques, techniques related tosupporting the TSB and techniques for supporting transport switching,which may be used alone, together, and/or in any combination with othertechniques described in this disclosure. For enabling the TSB feature inRTP-based streaming over eMBMS, this disclosure describes techniques forusing the extension of the SDP mechanism to signal the time-shiftedbuffer depth value. For the transport switching problem, this disclosuredescribes a unified approach for an SDP description that includes bothunicast and broadcast descriptions. Also, in order to make thetransitions between broadcast and unicast seamless to theapplications/users, this disclosure describes a middleware-basedsolution where the middleware handles the redirection of content usingunified SDP, hiding the process from the users.

In accordance with aspects of the subject matter of this disclosure,there are provided methods, apparatus, and an architecture fordeployment within a client device or collection of devices, to provide alayer of abstraction wherein multiple different types of transportmechanisms/protocols (e.g., eMBMS, digital video broadcast (DVB), etc.)may be employed to, e.g., deliver meta-data and digital content toapplications of a client. Applications need not be cognizant of thedetails of each individual transport. The disclosure may include theoption of a configurable set of policies which may be used to determinethe choice, location, or timing of availability of data and meta-datathat are delivered to the applications.

Applications that access web content on the Internet may identify thecontent (or its constituent parts) using a universal resource identifier(URI), which may be a universal resource locator (URL) that utilizes theHTTP or HTTP secure (HTTPS) schemes. For example, in the context ofMPEG-DASH, URL references containing the HTTP or HTTPS schemes may beresolved using the HTTP or HTTPS protocols. In addition, HTTP may beused to fetch data referenced by the URLs. The DASH standard may utilizenon-HTTP URLs, and the disclosure may relate to cases where arbitraryrequests (including HTTP-based requests) from clients are handled in aflexible manner that provides an option to cause requests to be directedto a different location, at a different time, and/or instruct therequesting client to access alternative content.

Techniques of this disclosure may involve the instantiation of are-director function that handles client requests for content. There-director (also referred to herein as a redirector/proxy) may be ableto apply processing to the material identified in a client request,invoke a method or algorithm to compare the result of this processingagainst a table of matching criteria, and indicate to the client analternative location, access method, timing information, or content(e.g., in a file) so that the client may know where to perform asubsequent request. In another aspect, the re-director may perform therequest for the content on the client's behalf and fetch the requestedcontent. In this case, the re-director may act in a proxy or recursivefunction.

FIG. 1 is a block diagram illustrating an example system 100 forsupporting transport diversity. The example system 100 may include anapplication 101, e.g., of a mobile device. The application 101 mayperform a request for content. For example, a DASH multimedia playbackapplication processes a manifest or MPD, and determines URLs containingmeta-data and data, and sends HTTP requests. The request for content mayuse a pre-determined, pre-configured, or dynamically determined protocolport (e.g., with TCP or UDP) such as a protocol that would typically beused in configuring a web browser's “proxy” function. The determinationof the protocol port may include using a configuration file, e.g.,established by a user or network/system administrator such as in a proxyauto-config (PAC) file, or via protocol such as by web proxyauto-discovery protocol (WPAD).

A re-director/proxy 104 may receive the application's 101 request via anapplication service client 102 and process or parse the request todetermine the requested content. The re-director/proxy 104 may comparethe result against a table (or other suitable type of data structure)containing matching criteria to determine if a match has occurred. If amatch occurs, the re-director/proxy 104 may determine a redirectiontarget. The target may be delivered to the application 101. In anotheraspect, the re-director/proxy 104 may act in a recursive fashion and theapplication 101 may not need to process the redirection target. Forexample, the re-director/proxy 104 may fetch the content based on theredirection target on behalf of the application 101.

The re-director/proxy 104 may be co-located with the application 101 onthe same device, or the re-director/proxy 104 may be located on aseparate device. In the case of a co-located re-director/proxy 104, theapplication 101 may communicate with the re-director/proxy 104 throughHTTP, application programming interface (API), inter-processcommunication (IPC), etc. In the case of the re-director/proxy 104located on a separate device, the application 101 may communicate withthe re-director (via the application service client 102) through HTTP,etc.

Subsequent to the determination of a “match” (or non-match), are-direction target may be provided to the application 101. The targetmay indicate alternative content object(s) to access in lieu of contentobject(s) requested by the application 101. There may be various methodsby which the re-direction target may be indicated to the application101.

Signaling between components of the system 100 may be performed using anAPI or IPC. This aspect, the API or IPC mechanism may be utilized toprovide communication between the re-director/proxy 104 and theapplication 101. In the case of using the API, the re-director/proxy 104may invoke methods or procedures implemented within the application 101or application library to indicate the redirect target.

Signaling between components of the system 100 may be performed throughmeta-data re-writing. In this aspect, the meta-data (e.g., a DASH MPD)may be re-written so as to indicate alternative references for objects.For example, a URI present in the original meta-data may be re-writtento form an alternative URI for accessing equivalent or replacementcontent.

Signaling between components of the system 100 may be performed usingindications in a communication protocol. In this aspect, an applicationlayer communications protocol (e.g., HTTP) may be utilized in such a wayas to communicate signaling information to the application 101. In onevariant, the HTTP response code category of “re-direct” may be used(e.g., this may correspond to codes of the form 3xx, where x may be anumber from zero through nine). In one subcase of this variant, e.g.,the code 300 (indicating multiple choices available) may be used, inwhich the re-director/proxy 104 provides a vector of references (e.g.,URIs) from which an application 101 may select one or more for use.

The matching function may give the result of comparing object referencesoriginated from the application 101 (e.g., a request URI) with objectreferences present in a data structure (e.g., a file, database, matchingtable, etc.).

By way of non-limiting examples, in one aspect, matching criteria may beexpressed as URI prefixes and a single preferred match occurs isindicated by the match with the longest prefix (e.g., as determined bythe number of bits or bytes in common). In another aspect, eachpotential match may be assigned a corresponding priority number, and theentry with the largest (or smallest) priority number may be selected.

In another aspect, matching criteria may be expressed as regularexpressions, and the preferred match may be determined using the largestnumber of matching characters. In another variation, regular expressionsmay be used to express the matching criteria and the potential matchwith the largest (or smallest) priority number may be selected.

The matching algorithm or contents of the data structure discussed abovemay be based on policies that may be pre-determined or pre-configured.In another aspect, the policies may be dynamically added or deleted froma logical policy database. The policy database may be implemented usingvarious data structures and is not limited to any particular type ofdata structure or database implementation.

Policies may be used to determine the operation of the matchingalgorithm in a number of ways including, for example, prioritizing orde-prioritizing matching criteria from one source over other(s) (e.g.,one transport type may be favor/disfavored over (s)); removing matchingcriteria as a function of source, time, redirection target, and/ormatching criteria value; adding matching criteria as a function ofsource or time or redirection target or matching criteria value; and/ormodifying matching criteria as a function of source or time orredirection target or matching criteria value.

The example system 100 may include a transport middleware 110 forrequesting content based on the redirected location. The transportmiddleware 110 may include a number of transport mechanisms/protocolsuch as Transport A 110A through Transport R 110R. Each transportmechanism (Transport A 110A through Transport R 110R) may have acorresponding module capable of acquiring a list and details of fileinformation and producing, e.g., a summarizing URI or common URI prefix.These modules may convey this information via a communication mechanism(e.g., IPC, API, or protocol) to the Controller 106 which may applypolicy and resolution, and which may in turn program there-director/proxy 104 subject to the policy. The transport mechanisms(Transport A 110A through Transport R 110R) may include, e.g., eMBMS,DVB-T2, DVB-S, other DVB-family broadcast technologies, or the like.Each transport middleware may include a cache for storing content orother data. For example, the transport middleware may cache a startingsegment of content so that content delivery to the application 101 mayappear instantaneous to the user. The transport middleware 110 mayrequest the content from a source such as a content server 120.Additionally or alternatively, the client may request the content over anetwork, including the Internet 122. For the re-director/proxy 104configured for proxy or “recursive” operation, the re-director/proxy 104may request content via the transport middleware 110 or via a network orthe Internet 122. The re-director/proxy 104 may be pre-configured tooperate in one of the re-direction or proxy roles. The role of there-director/proxy 104 may be determined at run-time, e.g., based on aset of rules.

FIGS. 2A-2B illustrate alternative examples of apparatuses including are-director/proxy 104 for supporting transport diversity. Any or all ofthe re-director/proxy 104, controller 106 with policy database 108, ortransport middleware 110 may be co-located with the application 101 andclient on a device or may be located on separate device(s). In theexample of FIG. 2A, the system 200A includes the re-director/proxy 104Awhich is shown co-located with the client and application 101 on a UE101A. For example, the application service client 102A may be a DASHclient, HTTP Live Streaming (HLS), Apple Live Streaming (ALS) client,Adaptive HTTP Streaming (AHS) client, or any other suitable client. Theapplication service client 102A may communicate with re-director/proxy104A via HTTP, API, IPC, or any other suitable protocol or manner. Inthe example of FIG. 2B, the system 200B includes the re-director/proxy104B which is shown located on a separate entity 110 as the applicationservice client 102B and application 101 which are located in a UE 101B.For example, the application service client 102B may be a DASH client,HLS (ALS) client, AHS client, or any other suitable client. Theapplication service client 102B may communicate with there-director/proxy 104B via HTTP, or any other suitable protocol ormanner. The re-director/proxy 104B may be located on any suitablenetwork entity such as a proxy server, gateway, router, etc.

FIG. 3 is a flow diagram illustrating aspects of an example process flow320 using a re-director/proxy configured for re-direction operation.Prior to initiation of the process flow 320, the policy database 108(coupled to the controller 106) may be provided or pre-configured withpolicy information for determining the actions of the controller 106.The policy database 108 may be provided with the information atprovisioning time.

The application 101, which may or may not be related to application 101in FIG. 1, may be a provisioning application. Application 101 may beconfigured to activate the transport middleware 110 (321), as well asdetermine status for transport middleware 110. Application 101 may beconfigured to activate one or more transport mechanisms of the transportmiddleware 110. Application 101 may initially configure applicationservice client 102 with information identifying a proxy endpoint (e.g.,a host name or address, protocol, or protocol port number) at startup(322).

In this example, more than one transport may be available and variouscontent may be available over the various transports at different times.In particular, various services may be available, where the variousservices may each define different respective types of transports, suchas broadcast, multicast, unicast, or the like, for transporting mediadata. For example, the eMBMS and/or one or more of the DVB-family oftransports may be available. Further, the available media content (e.g.,files) may be expressed using, e.g., an application service description.One example of an application service description is an MBMS userservice description (USD) metadata fragment, such as an MPD fragment inthe case of DASH content delivered as an MBMS User Service, indescribing the various available media components. Another example of anapplication service description is an Apple HLS (HTTP Live Streaming)manifest file, in the case of HLS content delivered as MBMS UserService. Each transport mechanism may have a corresponding modulecapable of acquiring the list and details of file information andproducing a summarizing URI or common URI prefix. These modules mayconvey this information via a communication mechanism (e.g., IPC, API orother protocol) to the controller 106 which may apply policy andresolution, and which in turn programs the re-director/proxy 104 subjectto the policy.

Content server 310 may broadcast (e.g., using LTE RAN, DVB-T, etc.) aservice listing (e.g., USD, ESG), which may be received by the transportmiddleware 110. An appropriate module (e.g., one of Transport A 110Athrough Transport R 110R) parses the service listing and processes theinformation into a form which is not transport specific. The transportmiddleware 110 may convey the results (e.g., an identifier of a serviceand data defining a list of available files, also referred to as a fileavailability list) to the controller 106 (324). The controller 106 mayprocess the file availability list in conjunction with the access policyto produce a set of mappings (325). The mappings may include which URIs(or URI prefixes) should be re-directed to which server (e.g., filesavailable over MBMS may be available from the server instantiated withinor associated with the MBMS middleware).

Once the application service client 102 is invoked, the applicationservice client 102 may issue a request (e.g., an HTTP request) via theconfigured proxy address to obtain, e.g., the MPD contents (326). Therequest may be communicated to the re-director/proxy 104. There-director/proxy 104 may perform the matching algorithm to determinematching criteria or, if a match does not occur, another indicator(e.g., a default re-direction target, error indication, or copy of theoriginal request). Redirector/proxy 104 may then provide a re-directiontarget or error to the application service client 102, e.g., using HTTP(327A). The application service client 102, having observed a code(e.g., HTTP code) indicating re-direction (e.g., 3xx type code) respondsdepending on the code type. For example, code types other than 300include an HTTP “Location:” header that may indicate the alternatelocation for a resource. Upon receiving such an indication, theapplication service client 102 may re-try its request using thealternate location indicated. In this example, the re-director/proxy 104indicates a particular URI should be directed to the server integratedwithin the MBMS middleware. Accordingly, the application service client102 may submit a request to the transport middleware 110 to obtain,e.g., the MPD (327B) in response to such a redirection code.

Once the application service client 102 has acquired the MPDinformation, the application service client 102 may determine whichmedia segments to access (e.g., which “representation” in the case ofMPEG-DASH) and issue an HTTP-based request (328) to the redirector/proxy104. Using the mechanism described above (e.g., the type of transportassociated with the service identified by the service ID), there-director/proxy 104 may provide a redirect target (329) to theapplication service client 102. The target may be a default value, acopy of the request (indicating the application service client 102should handle the request), or a reference to a different server. Thetargets then serve as the locations used by the application serviceclient 102 to obtain media segments. That is, assuming that the contentis available using the service, the application service client 102 maysubmit a content request to the transport middleware 110 (330A), and inresponse, the transport middleware 110 may deliver the content to theapplication service client 102 (331A). For content available throughother sources (e.g., when the service is not available), the applicationservice client 102 may obtain the content via other methods (e.g., fromother servers, storage/cache or the Internet). For example, theapplication service client 102 may send a content request to contentserver 310 (330B), and, in response, the content server 310 may deliverthe requested content to the application service client 102 (331B).

In some cases, the URIs requested from the application service client102, at step 326 or step 328, may be unknown to the re-director/proxy104. In such cases, errors (e.g., HTTP code 404) may be generated toindicate to the application service client 102 that it may try torequest a different segment or stop using the re-director/proxy 104(e.g., use a direct Internet access request instead). Alternatively, there-director 104 may use a location header equivalent to the incomingrequest to suggest non-proxy operation. Another aspect may involve there-director/proxy 104 acting as a proxy or web proxy, in which case itmay access the Internet or another network or cache on behalf of theapplication service client 102, e.g., as illustrated below in exampleprocess flow 400 of FIG. 4.

For the 300-type HTTP error codes, the application service client 102may be presented with a vector of choices that may not be present in the“Location:” header. In this case, the application service client 102 maychoose among the multiple choices provided and, depending on theparticulars of the media encoding format, re-initialize its decodingstate. The scenario may arise, for example, if a re-direction occurs inthe middle of a playback scenario to a representation encoded in a wayother than that which the application service client 102 has beenprocessing so far.

Whichever process the application service client 102 uses to select itsnext media request(s)/access(es), the application service client 102 mayinitiate the request(s)/access(es) based on the re-directed information.Subsequent requests/access may pass through the re-director initially,providing the opportunity for the re-director to intervene andeffectively modify the location (and other characteristics) from whichsegments (e.g., meta-data and/or media segments stored as files) areretrieved.

FIG. 4 is a flow diagram illustrating aspects of an example process flow400 using a re-director/proxy configured for proxy operation. Prior toinitiation of the process flow 400, the policy database 108 (coupled tothe controller 106) may be provided or pre-configured with policyinformation for determining the actions of the controller 106. Thepolicy database 108 may be provided with the information at provisioningtime.

The application 101 may be a provisioning application. Althoughdescribed with respect to application 101 of FIG. 1, it should beunderstood that the application need not be the same as that describedwith respect to FIG. 1. Application 101 may be configured to activatethe transport middleware 110 (401). Application 101 may be configured toactivate one or more transport mechanisms of the transport middleware110. The application service client 102 may initially be configured withinformation identifying a proxy endpoint (e.g., a host name or address,protocol, or protocol port number) at startup by the application 101(402).

In this example, more than one transport mechanism may be available andvarious media may be available over the various transports at differenttimes. The various types of transports may be defined by respectiveservices. For example, the eMBMS and/or one or more of the DVB family oftransports may be available. Further, the available media files may beexpressed using, e.g., the MPD fragment of the eMBMS USD, and via DVBelectronic service guide (ESG) for DVB transport. Each transportmechanism, represented by the transport middleware 110, may have acorresponding module capable of acquiring a list of available servicesand details of file information and for producing a summarizing URI orcommon URI prefix. These modules may convey this information via acommunication mechanism (e.g., IPC, API or other protocol) to thecontroller 106 which may apply policy and resolution, and which in turnprograms the re-director/proxy 104 subject to the policy.

Content server 310 may broadcast a service listing (e.g., USD, ESG) andreceived by the transport middleware 110 (403). An appropriate module(e.g., one of Transport A 110A through Transport R 110R) parses theservice listing and processes the information into a form which is nottransport specific. The transport middleware 110 may convey the resultsto the controller 106 (404). The controller 106 may process the fileavailability list in conjunction with the access policy to produce a setof mappings (405). The mappings may include which URIs (or URI prefixes)should be re-directed to which server instantiated (e.g., files or mediaavailable over MBMS may be available from the server instantiated withinor associated with the MBMS middleware).

Once the application service client 102 is invoked, the applicationservice client 102 may issue a request (e.g., an HTTP request) via theconfigured proxy address to obtain, e.g., the MPD contents (406). Therequest may be communicated to the re-director/proxy 104. There-director/proxy 104 may perform the matching algorithm to determinematching criteria or, if a match does not occur, another indicator(e.g., a default re-direction target, error indication, or copy of theoriginal request). In the case of an error, the error may be provided tothe application service client 102. If a match occurs, there-director/proxy 104 may act as a proxy and retrieve the content onbehalf of the application service client 102. The targets then serve asthe locations used by the re-director/proxy 104, acting as a proxy, toobtain media segments. That is, the redirector/proxy 104 may submit acontent request to the transport middleware 110 (407A), and thetransport middleware may deliver the content to the redirector/proxy 104(408A). For content available through other sources, there-director/proxy 104, acting as a proxy, may obtain the content viaother servers, from storage/files or the Internet. That is, theredirector/proxy 104 may submit a content request to content server 310(407B), and the content server 310 may deliver the requested content tothe redirector/proxy (408B).

FIG. 5 is a flowchart illustrating an example method for supportingtransport diversity associated with multimedia content for a multimediaclient of a wireless communications network (WCN). The multimedia clientmay be, or may include, a mobile entity. The method 500 may includereceiving a request for content, at 502. The method 500 may includedetermining whether a match exists for the request based on a set ofrules, at 504. The method 500 may include in response to determining amatch exists, sending a re-direction to the multimedia client, at 506.

FIG. 6 is a block diagram illustrating an example apparatus 600 that maybe configured as a UE, network entity, or other suitable entity, or as aprocessor, component or similar device for use within the UE, networkentity, or other suitable entity, for supporting transport diversityassociated with multimedia content for a multimedia client of a wirelesscommunications network (WCN). The apparatus 600 may include functionalblocks that can represent functions implemented by a processor,software, or combination thereof (e.g., firmware).

As illustrated, in one example, the apparatus 600 may include anelectrical component or module 602 for receiving a request for content.The apparatus 600 may include an electrical component or module 604 fordetermining whether a match exists for the request based on a set ofrules. The apparatus 600 may include an electrical component or module606 for sending a re-direction to the multimedia client in response todetermining a match exists.

In related aspects, the apparatus 600 may optionally include a processorcomponent 610 having at least one processor, in the case of theapparatus 600 configured as a network entity. The processor 610, in suchcase, may be in operative communication with the components 602-606 orsimilar components via a bus 612 or similar communication coupling. Theprocessor 610 may effect initiation and scheduling of the processes orfunctions performed by electrical components or modules 602-606.

In further related aspects, the apparatus 600 may include a networkinterface component 614 for communicating with other network entities.The apparatus 600 may optionally include a component for storinginformation, such as, for example, a memory device/component 616. Thecomputer readable medium or the memory component 616 may be operativelycoupled to the other components of the apparatus 600 via the bus 612 orthe like. The memory component 616 may be adapted to store computerreadable instructions and data for performing the activity of thecomponents 602-606, and subcomponents thereof, or the processor 610. Thememory component 616 may retain instructions for executing functionsassociated with the components 602-606. While shown as being external tothe memory 616, it is to be understood that the components 602-606 canexist within the memory 616.

FIGS. 7 and 8 are block diagrams that illustrate further aspects forsupporting transport diversity. The components of FIGS. 7 and/or 8 maycorrespond substantially to the components of FIG. 1 described above.FIG. 7, for example, illustrates network 700, application service client702, media application 704, HTTP redirector/proxy 706, controller 708,middleware 712, and policy manager 716. Media application 704 isgenerally responsible for selecting media content (e.g., in response toa user's selection), and application service client 702 is configured toretrieve the selected media content and provide the retrieved mediacontent to media application 704 for playback. Application serviceclient 702 may comprise, for example, a DASH client configured toutilize HTTP to stream media data.

As discussed above with respect to FIG. 1, application service client702 may retrieve media data either directly from network 700 or frommiddleware 712. For example, when a service supporting broadcast ormulticast is available (e.g., as determined by controller 708 anddefined by policies stored by policy manager 716), middleware 712 mayreceive media data and store the received media data within cache 714.Application service client 702 may issue requests for media data to HTTPredirector/proxy 706. When the requested media data has been received bymiddleware 712, HTTP redirector/proxy 706 may redirect a request for themedia data to middleware 712. Thus, application service client 702 mayissue an HTTP request to middleware 712, which may provide the mediadata to application service client 702. On the other hand, whenmiddleware 712 has not received the media data, HTTP redirector/proxy706 may redirect application service client 702 to a network location ofa server from which the media data is available, where the server may beavailable via network 700.

FIG. 8, as another example, illustrates DASH client 802, playbackapplication 804, HTTP redirector/proxy 818, controller 814, MSDC 808,MBMS transmission unit 820, and policy database 816. These componentsmay correspond substantially to the similarly named components in FIGS.1 and/or 7. In general, the techniques of FIG. 8 are discussed asutilizing DASH (which in turn utilizes HTTP), but it should beunderstood that other streaming protocols may be used as well.Alternative examples are discussed below with respect to RTP/RTSP, forinstance.

Initially, policy information may be provided to the system includingDASH client 802, playback application 804, HTTP redirector/proxy 818,controller 814, and MSDC 808. Such policy information may be storedwithin policy database 816 (830). This policy information may influencethe action of controller 814. Controller 814 may be implemented inhardware, software, firmware, or any combination thereof. It is presumedthat, when implemented in software and/or firmware, requisite hardwaremay is also provided, such as one or more hardware-based processingunits for executing instructions of software corresponding to controller814.

Initially, playback application 804 may provision identifyinginformation, such as information identifying a proxy endpoint (e.g.,host name or address, protocol, and protocol port number) (832). Thisinformation may be provided by an optional provisioning application.DASH client 802 may be configured with the identifying information(834).

In the example of FIG. 8, more than one transport may be available andvarious media (e.g. in files) may be available over the varioustransports at different times. Consider, for example, that the eMBMS andDVB transports are available. Further consider that the media filesavailable are expressed using an application service description. Eachtransport may have a corresponding module capable of acquiring the listand details of media information and producing a summarizing URI orcommon URI prefix, as shown by transport modules 110A-110R of FIG. 1.Only MSDC 808 is shown in the example of FIG. 8, but it should beunderstood that MSDC 808 may include multiple respective transportmodules. These modules convey the file information via a communicationmechanism (e.g., IPC, API or protocol) to controller 814, which mayapply policy and resolution, and which in turns programs the re-directorsubject to policy. FIG. 8 depicts only the portions for MBMS (to limitclutter). MBMS rX 820 may receive the USD (836), and parse/deliver theUSD to MSDC 808 (838).

MSDC 808 processes the USD-specific information into a form which is nottransport-specific and conveys the results to controller 814 (840).Controller 814 may then process the file availability list inconjunction with the access policy to produce a set of mappings (842).The mappings indicate which URIs (or URI prefixes) should be re-directedto which server instantiated (e.g., files available over MBMS may beavailable from server 812, instantiated within or associated with MSDC808). In other words, HTTP redirector/proxy 818 may obtain mappinginformation that maps an identifier for media data to a resourcelocation based on a service for retrieving the media data, wherein theservice defines at least one of a plurality of types of transports(e.g., broadcast, unicast, or multicast) for transporting the mediadata. For example, the service may define broadcast or multicasttransport types for transporting the media data, in which case MSDC 808may receive the data. MSDC 808 may store received media data in cache810, for subsequent retrieval by, e.g., DASH client 802, as discussedbelow.

Once invoked, DASH client 802 may issue an HTTP request via theconfigured proxy address (to HTTP redirector/proxy 818) to obtain theMPD contents (844). Likewise, HTTP redirector/proxy 818 may receive theHTTP request from DASH client 802. The HTTP request may be a request formedia data. HTTP redirector/proxy 818 may perform the matching algorithmto determine matching criteria or, if a match does not occur, anotherindicator (e.g., a default re-direction target, error indication, orcopy of the original request). Thus, using the matching criteria on themapping information, HTTP redirector/proxy 818 may determine whether aparticular service is available, e.g., a service defining broadcast ormulticast for transporting the requested media data. HTTPredirector/proxy 818 may then provide a re-direction target or error toDASH client 820 using HTTP (846), based on the matching algorithm.

DASH client 802, having observed an HTTP code indicating a re-direction(e.g., a 3xx type HTTP code) may respond depending on the code type. Fortypes other than 300, an HTTP “Location:” header may indicate thealternate location for a resource. Upon receiving such an indication,DASH client 802 may re-try its request using the indicated alternativelocation. In this example, HTTP re-director/proxy 818 may indicate thata particular URI should be directed to the server integrated within MSDC808, from which DASH client 802 may obtain the MPD (848).

Once DASH client 802 has acquired the MPD information, DASH client 802may determine what media files to access (e.g., which “representation”in the case of MPEG-DASH) and issue one or more HTTP-based requests toretrieve the determined media files (852). Using the mechanism describedabove, HTTP redirector/proxy 818 provides a redirect target to DASHclient 802 (854). The target may be a default value, a copy of therequest (indicating the client should handle the request), or areference to a different server. The targets then serve as the locationsused by DASH client 802 to obtain media segments, e.g., from MSDC 808(856). In this manner, when a service defining, e.g., broadcast ormulticast for transporting media is available, HTTP redirector/proxy 818may cause DASH client 802 to receive the requested media data from aunit (e.g., MSDC 808) that receives the media data using the servicefrom the resource location indicated in the mapping information.Alternatively, the redirection target may correspond to a networklocation available via some network, including Internet 806.

In some cases, the URIs requested from the client (steps 844/852) may beunknown to HTTP redirector/proxy 818. In such cases, errors (e.g., HTTPcode 404) could be generated to indicate to DASH client 802 that DASHclient 802 should try to request a different segment or change to notuse HTTP redirector/proxy 818 (i.e., instead use a direct network orInternet access request). Alternatively, HTTP redirector/proxy 818 mayuse a Location: header equivalent to the incoming request to suggestnon-proxy operation. One further variant would involve HTTPredirector/proxy 818 acting as a conventional web proxy, in which caseHTTP redirector/proxy 818 may access Internet 806 on behalf of DASHclient 802.

In this manner, the techniques of FIG. 8 represent an example of amethod including, by a proxy unit (e.g., HTTP redirector/proxy 818),obtaining mapping information that maps an identifier for media data toa resource location based on a service for retrieving the media data,wherein the service defines at least one of a plurality of types oftransports (e.g., broadcast, multicast, or unicast) for transporting themedia data, receiving a request for the media data from an applicationservice client (e.g., DASH client 802), determining whether the serviceis available, and, when the service is available, causing theapplication service client to receive the media data from a unit thatreceives the media data using the service from the resource location,based on the mapping information. The unit that receives the media data,in this example, corresponds to MSDC 808.

Furthermore, if the resource location corresponds to a network location(e.g., a location within or accessible via Internet 806), HTTPredirector/proxy 818 may be configured to determine whether media dataspecified in a request matches media data in mapping information, andwhen the media data specified in the request matches the media data inthe mapping information, send a redirect message to the applicationservice client specifying the network location to which the identifierfor the media data is mapped in the mapping information to cause theapplication service client to retrieve the media data from the networklocation.

Likewise, HTTP redirector/proxy 818 represents an example of a proxyunit configured to obtain mapping information that maps an identifierfor media data to a resource location based on a service for retrievingthe media data, wherein the service defines at least one of a pluralityof types of transports (e.g., broadcast, multicast, or unicast) fortransporting the media data, receive a request for the media data froman application service client, determine whether the service isavailable, and, when the service is available, cause the applicationservice client to receive the media data from a unit that receives themedia data using the service from the resource location, based on themapping information.

FIGS. 9 and 10 are block diagrams illustrating example MSDCarchitectures for supporting RTP/RTSP streaming. FIG. 9 shows thearchitecture without the TSB feature and FIG. 10 shows the architecturesupporting a TSB. In these examples, the TSB will be maintained in themiddleware. The numbered arrows indicate the data flow from a networklayer to middleware and eventually to the RTSP/RTP client. Inparticular, data received by the LTE modem is provided to the IP stack,which supports multicast (or broadcast). The IP stack provides thereceived data to a Real-time Transport Protocol (RTP) function of theMSDC middleware (901), which performs forward error correction (FEC)processing on the data. The data is then provided back to the IP stack(902). The IP stack then provides the data to the RTP client (903).

In the example of FIG. 10, MSDC 1010 may support TSB 1012. Thus, in theexample of FIG. 10, data received by the LTE modem is provided to the IPstack, which supports multicast (or broadcast). The IP stack providesthe received data to a Real-time Transport Protocol (RTP) function ofMSDC 1010 (1001), which performs forward error correction (FEC)processing on the data. The data is then buffered in a time-shiftedbuffer (TSB) 1012 (1002). The IP stack may then receive the data fromTSB 1012 (1003) at an appropriate time and provide the data to the RTPclient (1004).

In addition, as described in greater detail below, MSDC 1010 may receivean SDP message including an attribute that defines a time-shifted buffer(TSB) depth for TSB 1012 of FIG. 10. MSDC 1010 may determine an amountof memory for TSB 1012 based on a value of the attribute as signaled inthe SDP message. For example, the value of the attribute may define alength of the TSB, e.g., in terms of seconds of playback for media datato be stored in TSB 1012. Thus, MSDC 1010 may determine the amount ofmemory to be allocated to form TSB 1012 based on, e.g., a frame rate forvideo data of the media data to be received and on the number of secondsof playback to be potentially buffered in TSB 1012. MSDC 1010 may thenallocate the determined amount of memory for TSB 1012 and store at leasta portion of received media data, associated with the SDP message, inTSB 1012.

In order to signal the TSB depth, the techniques of this disclosure maybe used to leverage the extension mechanism of SDP. SDP “a=” (attribute)lines may be used for providing extensions to the general sessiondescription. The following semantics may be used to signal data relatedto the TSB, as one example:

-   -   TSB-attribute=“a=tsb-length:” Value    -   Value=token        -   Value will have seconds as unit

As an example, the following SDP snippet mentioned in Table 1 describesdata for the TSB. The buffer depth in this example is 60 seconds, or 1minute. This implies that the MSDC (e.g., the TSB of the MSDCillustrated in FIG. 10) will maintain 1 minute worth of media content inits time-shifted buffer. The underlined text represents an exampleattribute in the form of an “a=” line, in accordance with the techniquesof this disclosure, related to the TSB.

TABLE 1 v=0 s=RTSP session c=IN IP4 127.0.0.1/1 a=3GPP-QoE-Metrics:metrics={Network_Resource|Loss_Of_Objects};rate=End;resolution=60 t=0 0 a=rtsp://localhost:554/concert a=tsb-length: 60a=control:trackID=1 m=audio 5676 RTP/AVP 0 a=control:trackID=2 m=video5677 RTP/AVP 31

When data for the TSB is provided in the SDP, the MSDC may allocate anequivalent amount of buffer of the size mentioned in the SDP, and mayallow the RTSP/RTP client to fast-forward or rewind playback, withrespect to the buffer duration.

One example technique for achieving transport diversity is based uponthe solution proposed by U.S. Provisional Application Ser. No.61/752,456, “ARCHITECTURE SUPPORTING TRANSPORT DIVERSITY,” to Fall etal., filed, Jan. 15, 2013, attorney docket no. 131286P1 (hereinafter,the “Fall provisional application”), the entire contents of which arehereby incorporated by reference. The Fall provisional applicationproposes common client architecture for supporting diverse transportprotocols. The techniques of this disclosure for supporting transportdiversity in RTP may be used to extend the techniques described in theFall provisional application, which relates to DASH-based delivery ofcontents.

Unlike the DASH protocol, where media representations in MediaPresentation Description (MPD) may change based on transport deliverymethods, RTP protocol conventionally has no way to differentiate thetransport diversity via a single SDP profile directly. This disclosuredescribes to example techniques to achieve transport diversity.

As one example, eMBMS broadcast definitions of services allow mechanismsto select between unicast and broadcast transport mechanisms. Forexample, a deliveryMethod element in an eMBMS service definition schemamay contain an SDP profile that describes broadcast delivery sessions,while an AlternativeAccessDelivery element may contain references to anRTSP URL for unicast access or PSS SDP file that denotes unicast SDPsession information. When a UE is under broadcast network coverage,eMBMS middleware may consume broadcast content using broadcast SDPsession information. Otherwise, the middleware may pass the content byconnecting to the unicastAccessURI in AlternateAccessDelivery. Anexample of the eMBMS user service description (USD) schema snippet isshown in FIG. 11.

An alternative example to the deliveryMethod carrying broadcast SDP andunicast access URI is to have a unified single SDP that contains bothunicast and broadcast session descriptions in different media streams.Since any session description in SDP can contain multiple media streamdefinitions (for example, one for an audio track and another for a videotrack), a mechanism may be used to group broadcast and unicast mediastreams into different sets to provide a unified SDP profile. This canbe achieved by a grouping method in SDP. An example of the groupingmechanism is described as follows:

-   -   Media stream identification        -   Identifies media streams within groups        -   Media-attribute=“a=mid:” Identification-tag        -   Identification-tag=token    -   Group attribute        -   Identifies unicast/broadcast media streams        -   Group-attribute=“a=group:” Semantics (identification-tag)*        -   Semantics=“BROADCAST”|“UNICAST”

The following snippet in Table 2 provides an example in which values areprovided for group and media stream identifier attributes. In theexample below, the “a=group:” lines denote which media streams are usedfor broadcast and which media streams are used for unicast. In thisexample, broadcast media streams are denoted by “a=mid:” values 1 and 2and unicast are denoted by “a=mid:” values 3 and 4, respectively.Therefore, middleware may connect to IP address 224.1.1.2 and ports30000 and 30002 for broadcast content, and to IP address 131.10.1.2 andports 26890 and 26892 for unicast streams.

TABLE 2 v=0 t=0 0 c=IN IP4 224.2.17.12/127 a=group:BROADCAST 1 2a=group:UNICAST 3 4 m=audio 30000 RTP/AVP 0 c=IN IP4 224.1.1.2/127a=mid:1 m=video 30002 RTP/AVP 31 c=IN IP4 224.1.1.2/127 a=mid:2 m=audio26890 RTP/AVP 31 c=IN IP4 131.10.1.2/127 a=mid:3 m=video 26892 RTP/AVP31 c=IN IP4 131.10.1.2/127 a=mid:4

In this manner, FIG. 10 illustrates an example of a device including oneor more processors configured to receive a session description protocol(SDP) message including an attribute that defines a time-shifted buffer(TSB) depth, determine an amount of memory for the TSB based on a valueof the attribute, allocate the determined amount of memory to the TSB,and store at least a portion of media data associated with the SDPmessage in the TSB.

FIGS. 12 and 13 are block diagrams illustrating example components forsupporting transport diversity for an RTSP/RTP client. WhetherdeliveryMethod in an eMBMS USD is used to differentiate betweenbroadcast and unicast transport, or the unified single SDP mechanism isused, the techniques of this disclosure may provide seamless contentacquisition by the RTSP/RTP client. In order to achieve that, asproposed in the Fall provisional application, a policy manager, acontroller, and an RTSP redirector/proxy may be maintained in UE,possibly outside eMBMS middleware (also referred to as a multicastservices device client (MSDC)). When an RTSP client asks for SDP, a RTSPredirector/proxy always provides SDP profiles that carry localhost(e.g., IP version 4 address 127.0.0.1) as the connection endpointaddress. The idea is that whether the RTSP redirector/proxy receivescontent via eMBMS middleware (for broadcast) or a unicast RTSP server(for unicast), it always serves the content to the RTSP/RTP client fromthe localhost. Therefore, the client is unaware of diversity in thetransport mechanism. Below we provide a brief description of the maincomponents of the architecture and give an example of how content isdelivered to the client.

In the examples of FIGS. 12 and 13, Playback App is the application thatis attempting to consume streaming content; RTSP/RTP Client is theclient that implements the RTP protocol for client behavior; eMBMSMiddleware is the middleware architecture that implements eMBMS (orMBMS) broadcast service discovery (for streaming or file download) andconsumes streaming or file delivery content via broadcast LTE network;Policy Manager maintains a database of policies as discussed above;Controller is a component that gets policy information from the policymanager and eMBMS broadcast coverage indication from the eMBMSmiddleware and provides a mapping to the RTSP redirector/proxy, statingwhich SDP profile to choose from (unicast or broadcast); and RTSPRedirector/Proxy is a proxy unit that receives mapping information fromthe controller and, depending on the mapping, collects RTP content fromeMBMS middleware (in case UE is in broadcast coverage) or connects tothe unicast RTSP URI and receives content via unicast transport, whichit may then pass to the RTSP/RTP Client.

FIG. 12 represents an example procedure for the broadcast delivery ofRTP content. FIG. 12 includes RTSP/RTP client 1202, playback application1204, RTSP redirector/proxy 1218, controller 1214, eMBMS middleware(also referred to as MSDC) 1208, policy manager 1216, and broadcasttransmission unit (also referred to as eMBMS rX) 1220. FIG. 12 alsodepicts Long Term Evolution (LTE) radio access network (RAN) 1206. LTERAN 1206 provides an MBMS service, which defines at least one of aplurality of types of transports (e.g., broadcast, multicast, orunicast) for media data. Thus, when MSDC 1208 is in a service area ofcoverage provided by LTE RAN 1206, MSDC 1208 can receive media data viaLTE RAN 1206 using broadcast or multicast transport. Furthermore, MSDC1208 implements server 1212, which includes cache 1210. In this manner,MSDC 1208 can act as both a client that receives media data and a serverthat provides data to, e.g., RTSP/RTP client 1202. Moreover, RTSP/RTPclient 1202 may retrieve media data from, e.g., MSDC 1208 or RTSPredirector/proxy 1218, and then provide the media data to playbackapplication 1204.

Playback application 1204 may correspond substantially to application101 (FIG. 1), while RTSP/RTP client 1202 may correspond substantially toapplication service client 102 (FIG. 1). Similarly, MSDC 1208 maycorrespond substantially to one of transport middleware 110A-110R (FIG.10). Controller 1214 may correspond substantially to controller 106(FIG. 1). RTSP redirector/proxy 1218 may correspond substantially toredirector/proxy 104 (FIG. 1).

In this example, the policy manager is provisioned with policies (1230).The eMBMS Middleware (or MSDC) 1208 receives USD descriptions (1232,1234) for the list of eMBMS services. The MSDC 1208 then passes the SDPprofile information for the RTP streaming service and the broadcastcoverage notification to the controller 1214 (1236), which in turnmatches the SDP information with the list of policies and providesmapping information to the RTSP redirector/proxy 1218 (1238). Mappinginformation contains data indicating, for each scenario (broadcast orunicast coverage), which SDP profile connection-endpoints to use. Inthis manner, the RTSP redirector may obtain mapping information thatmaps an identifier for media data to a resource location based on aservice for retrieving the media data. The resource location maycorrespond to a network address, e.g., an address available via LTE RAN1206. The service may define at least one of a plurality of types oftransports for transporting the media data, e.g., broadcast ormulticast.

The MSDC 1208, meanwhile, passes a list of services to the playbackapplication 1204 (1240). The playback application 1204 may correspond toapplication 101 (FIG. 1). The playback application 1204 then passes theRTSP URI (provided with the list of services from MSDC) and the proxyaddress to the RTSP/RTP client 1202 (1242). When the RTSP/RTP 1202client calls DESCRIBE command (an RTSP defined command) (1244), the RTSPredirector/proxy 1218 provides a modified SDP message redirected tolocal server (1246). The RTSP/RTP client 1202 parses the SDP information(1248) and calls the SETUP command (RTSP command) to set up a RTPsession with the local server. The RTSP/RTP client 1202 also passes thePLAY command when setup with the server succeeds (1250). The RTSPredirector/proxy 1218 provides a success message to the SETUP and PLAYrequest (1252) to the RTSP/RTP client 1202. The SETUP and PLAY commandsreceived by the RTSP redirector/proxy 1218 from RTSP/RTP client 1202represent an example of a request for media data. In addition, the RTSPredirector/proxy 1218 sends SETUP and PLAY commands to the MSDC 1208(1251).

RTSP redirector/proxy 1218 may determine whether the service forretrieving media data is available, e.g., whether a service that definesbroadcast or multicast as a transport is available. RTSPredirector/proxy 1218 may determine whether the service is availablebased at least in part on whether RTSP redirector/proxy 1218, or MSDC1208, is within a service coverage area. The techniques of FIG. 12presume that the service is available. FIG. 13, as discussed in greaterdetail below, describes additional techniques that may be employed whenthe service is not available.

Meanwhile, during the active broadcast session of the streaming service,a network operator sends RTP content over LTE RAN 1206 (1254). MSDCcollects RTP content for the service from broadcast connection endpoint(labeled eMBMS rX 1220 in FIG. 12) (1256), processes the content (ifneeded), and passes the content to the RTSP/RTP client 1202 at anendpoint specified by the client during the SETUP command with the RTSPredirector/proxy (1258). In this manner, when the service is available(e.g., a service defining broadcast or multicast transport), RTSPredirector/proxy 1218 causes RTSP/RTP client 1202 to receive media datafrom MSDC 1208 (i.e., a unit that receives the media data using theservice from a resource location, e.g., via LTE RAN 1206). Inparticular, in this example, MSDC 1208 receives media data from anetwork location via LTE RAN 1206, based on mapping information (e.g.,the USD data described above) that maps the service to this location.

In this manner, the techniques of FIG. 12 represent an example of amethod including, by a proxy unit (e.g., RTSP re-director/proxy 1218),obtaining mapping information that maps an identifier for media data toa resource location based on a service for retrieving the media data,wherein the service defines at least one of a plurality of types oftransports (e.g., broadcast, multicast, or unicast) for transporting themedia data, receiving a request for the media data from an applicationservice client (e.g., RTSP/RTP client 1202), determining whether theservice is available, and, when the service is available, causing theapplication service client to receive the media data from a unit thatreceives the media data using the service from the resource location,based on the mapping information. The unit that receives the media data,in this example, corresponds to MSDC 1208.

FIG. 13 represents an example procedure for the unicast delivery of RTPcontent. In this example, steps 1232-1248 are substantially the same asthe broadcast delivery of content as described with respect to FIG. 12.However, in this case, when RTSP/RTP client calls SETUP and PLAYcommands (1310), the RTSP redirector/proxy 1218 contacts a unicast RTSPserver via RAN/Internet 1302 from the mapping information (1312),retrieves the contents from the unicast RTSP server (1314), and passesthe content to the endpoint mentioned by the RTSP/RTP client 1202 duringSETUP command or the ones announced in the SDP at step 1246 (1316).Therefore, in this case, the RTSP redirector/proxy 1218 (which may bepresent in user equipment that also includes RTSP/RTP client 1202) actsas client to the remote RTSP server and retrieves the content onRTSP/RTP client's behalf.

In this manner, the techniques of this disclosure may use an SDPextension mechanism (attribute) to provide TSB indication for eMBMSbroadcast delivery of RTP content. This disclosure also defines anexample architecture to support seamless transition between broadcastand unicast transport, and to provide RTP media content deliverymechanisms within a UE. Moreover, this disclosure describes techniquesfor grouping of multiple RTP-based media streams for unicast andbroadcast delivery of content within an SDP message.

RTSP redirector/proxy 1218 represents an example of a proxy unit thatmay be configured to obtain mapping information that maps an identifierfor media data to a resource location based on a service for retrievingthe media data, wherein the service defines at least one of a pluralityof types of transports (e.g., broadcast, multicast, or unicast) fortransporting the media data, receive a request for the media data froman application service client, determine whether the service isavailable, and, when the service is available, cause the applicationservice client to receive the media data from a unit that receives themedia data using the service from the resource location, based on themapping information.

FIGS. 14A and 14B are conceptual diagrams illustrating an example XMLcontent model for extending a USD to carry DASH Transport information.The circled A represents a point at which connections between FIGS. 14Aand 14B are joined. The XML content model may be used alone or incombination with any of the techniques described above. For example, thecomponents of FIGS. 1, 2A, 2B, 6, 7, and/or 8 may be configured toutilize the XML content model described with respect to FIGS. 14A and14B. As discussed above, the techniques of this disclosure includetechniques for selecting between unicast and broadcast transport modes.FIG. 14B illustrates data defining both a broadcast representation(broadcast element in the USD) and a unicast representation (unicastelement in the USD).

In accordance with certain techniques of this disclosure, an applicationservice client, such as a DASH client (e.g., the DASH client of FIGS. 1,2A, 2B, 6, 7, and/or 8), may make an initial selection of arepresentation from which to retrieve a Segment. In particular, the DASHclient may make such an initial selection while remaining agnostic ofthe transport mode (broadcast and/or unicast) of the Representation towhich the requested Segment belongs. Assume, for purpose of example,that HTTP is used by the DASH client in requesting Segments of aselected Representation, as well as the extended USD shown in FIG. 14Bis used to carry DASH Transport information. Each of the one or morebroadcast Representations is identified in the USD by a unique baseURLattribute of the broadcast element.

Each instance of broadcast maps to a unique Representation deliveredover the MBMS bearer. Its baseURL will be compared to a portion of theSegment URL used by the DASH client to request Segments—specifically,the initial portion of the Segment URL starting from the URI scheme andextending to and inclusive of the identifier of the Representation towhich the Segment belongs, to determine whether that Representation isbeing requested.

For example, assume the Segment URL issued by the DASH client to be“http://example.com/per-3/rep-512/seg-99.3gp”, corresponding to arequest for Segment 99 of Representation 512 (Representation@id=‘512’)in Period 3 (Period@id=‘3’). The portion of this URL of concern for thepurpose of matching with the basesURL in the USD is“http://example.com/per-3/rep-512. In the event that this Representationis also available over broadcast, an instance ofmediaPresentationDescription2.broadcast will be present in the USD withbaseURL given by “http://example.com/per-3/rep-512”, identical to theportion interest in the request URL. For instance, a match in theportion of interest for the request URL to the baseURL attribute of theUSD's broadcast element denotes broadcast transport of theRepresentation to which the requested Segment belongs.

Similarly, each of the zero or more unicast Representations, in thisexample, is identified in the USD by a unique baseURL attribute of themediaPresentationDescription2.unicast element. A matching pattern in thesame portion of the request URL as discussed above to the unicastbaseURL implies that this Representation is available over unicastdelivery. The same Representation may be available over both, one-only,or neither of the transport modes.

The entity to which the DASH client submits the Segment request may be aproxy unit (or to an MBMS or eMBMS client). For purposes of example, theproxy unit is described below as performing these techniques, but itshould be understood that the MBMS or eMBMS of, e.g., FIGS. 1, 2A, 2B,6, 7, and/or 8 may be configured to perform the techniques attributed tothe proxy unit, as described below. By using pattern matching betweenthe portion of interest for the request URL to the value of baseURL inthe broadcast and unicast elements in the USD, the proxy unit maydetermine whether the selected transport mode is available and/orpreferable to another transport mode.

The proxy unit may retrieve a policy that indicates preferences amongtypes of transports. For example, the policy may indicate that if therequest is for a Representation delivered over unicast, as long as thedevice is located in a broadcast coverage area, only abroadcast-delivered Representation should be accessible to the DASHclient. Such a broadcast Representation may be the same Representationas original requested, if the baseURL appears in the USD'sidenticalContent element, and can be substituted for the requestedRepresentation, albeit delivered over a different transport mode.

Alternatively, the broadcast Representation may be an alternativeRepresentation known to be delivered over broadcast, and is considered aswitchable Representation, since the baseURL for the alternativeRepresentation appears in the list of entries of the USD elementswitchableContent. In this case, the proxy unit may send a message backto the DASH client to cause the DASH client to request the same Segmentbelonging to an alternative Representation which is delivered overbroadcast. For instance, the proxy unit may send a 300-type HTTPresponse message to the DASH client, which corresponds to a redirectmessage, and the redirect message may specify a resource URLcorresponding to the alternative representation from the list containedin switchableContent.

As another example, if the DASH client requested a Segment known to theproxy unit to be delivered over broadcast but broadcast reception is notavailable (e.g., due to a client device being out of a coverage area forbroadcast transport), the proxy unit may send a 300-type HTTP responsemessage that includes a URL of a Segment corresponding to a unicasttransport of the same, or a different Representation if that sameRepresentation is not available over unicast transport, but appears asan entry in switchableContent.

As another example, if the DASH client requested a Segment known to theproxy unit to be delivered over broadcast and broadcast reception isavailable, the proxy unit will proxy the request to the local contentcache, and deliver the retrieved Segment back to the DASH client.

Alternatively, the proxy unit may respond with a 400-type error message,which may cause the DASH client to re-submit a request using a differentSegment URL. The proxy unit may communicate a different transportprotocol in other ways as well, e.g., via an application programminginterface (API), inter-process communication (IPC), sending a modifiedMPD that omits the selected base URL, or the like.

The redirect or error message from the proxy unit may cause the DASHclient to select a different transport mode. In some examples, more thanone Representation may be available on the redirected transport mode, inwhich case the DASH client may select from among one of those availableRepresentations. As an example, if the DASH client had attempted toselect a broadcast Representation (as given by an instance of thebroadcast element of FIGS. 14A and 14B), but the proxy unit determinedthat broadcast reception is not available, the proxy unit may send amessage (e.g., a 300-type redirect message, a 400-type error message, anAPI call, via IPC communications, or the like) to the DASH client tocause the DASH client to instead select the unicast Representation ofFIGS. 14A and 14B.

In some instances, an application service client, such as the DASHclient, may be tasked with managing unicast-broadcast transitions. Thisdisclosure describes, with respect to FIGS. 14A and 14B as one example,a framework for extending the USD with additional parameters that may,in the case of DASH over MBMS download delivery, enable an MBMS clientto determine whether Segment requests from a DASH client can be servedas-is, or only from one or more alternative Representations. The USD mayindicate the transport mode (broadcast-only, unicast-only, or bothbroadcast and unicast) of each Representation specified in the MediaPresentation Description (MPD). Example scenarios for rules andmechanisms for determining Representation availability are describedbelow.

In one example, user equipment (UE) may be located within an MBMScoverage area, and the DASH client may request a particularRepresentation that the USD indicates is unavailable via broadcastdelivery. Service provider policy may dictate that whenever the UE is inMBMS coverage, only broadcast-delivered Representations of the sameprogram can be accessed. In this situation, the DASH client may belimited to selecting (or redirected or instructed to select) from amongthe alternative Representation(s) available over broadcast delivery.

In another example, UE may be located within MBMS coverage, and the DASHclient may request a Representation that is known to be available overbroadcast delivery. In this situation, the desired Representation can bedirectly accessed by the UE.

In another example, UE may be outside MBMS reception area, and the DASHclient may request a Representation that is known to be only availableover broadcast delivery. In this situation, the DASH client may belimited to selecting (or redirected or instructed to select) from amongthe alternative Representation(s) available over unicast delivery, inthe form of switchable content(s).

In another example, UE may be outside MBMS reception area, and the DASHclient may request a Representation that is known to be also availableover broadcast delivery. In this situation, the DASH client may be ableto receive the same Representation over unicast, in the form ofidentical content.

Additional information that may be carried in the USD includes theindication of the service area(s) over which each Representation isdelivered, and/or the identification of the SDP that describes the FLUTEsession carrying that Representation.

This disclosure describes techniques by which amediaPresentationDescription2 child element may be added underuserServiceDescription to carry additional transport parameters.Previously, it was proposed that MPD-specific parameters, such as PeriodID, Adaptation Set ID, and Representation ID be contained inmediaPresentationDescription2, which may identify those Representationsavailable over unicast delivery. These same parameters, along with URIreference to a Session Description fragment, may identify eachRepresentation that can be delivered over broadcast, as well as themapping to the FLUTE session carrying the Segments of thatRepresentation.

One issue that the techniques of this disclosure may overcome is withregards to enabling the use of HTTP/1.1 as the protocol interfacebetween the DASH client and the MBMS client for Segmentrequest/response, while maintaining clean layering separation inprotocol processing. For instance, in previous techniques, the MBMSclient has to process MPD-specific information to be able to correlatethe DASH client request for Segments of a particular Representation toan actually available and permitted (e.g. in accordance to serviceprovider policy) Representation Segments by transport mode (broadcast orunicast). In the event that a requested Representation cannot beprovided, in order for the MBMS client to use HTTP Redirection (via 3xxresponse codes as defined in Fielding et al., “Hypertext TransferProtocol—HTTP/1.1,” Network Working Group, RFC 2616, June 1999 availableat http://www.ietf.org/rfc/rfc2616.txt) to inform the DASH client of oneor more alternative Representations, the MBMS client will have tocompose a complete Segment URI for each alternative resource. Such alayering violation on the part of the MBMS client can be eliminatedthrough the use of the techniques of this disclosure.

The techniques of this disclosure eliminate the need for the MBMS client(or proxy unit) to be aware of or have to process (DASH-specific) MPDinformation. The MBMS client merely performs data/pattern matching,based on the presence of new metadata in the USD, with the Segmentrequest URIs generated by the DASH client, in determining whether therequested Segment is available over broadcast, unicast, neither or bothtransport modes, or by some other fashion (e.g., cache). This ispossible because the portion of the request URI that uniquely identifiesthe Representation to which the requested Segment belongs is alsoconveyed in the USD. In addition, the MBMS client can determine whetherthe Representation requested by the DASH client (which is agnostic tothe transport mode) is available over broadcast, unicast, neither orboth transport modes, or by some other fashion (e.g., cache), by thelocation of the matching data pattern in the USD. In conjunction withany other relevant rules and conditions, such as coverage condition(whether the UE is in unicast and/or broadcast service area), serviceprovider policy, etc., and assuming that the substitution method forreturning the alternative resource URI is allowed based on the USDattribute replacementAllowed=‘true’. The MBMS client can use HTTP/1.1mechanisms to mediate Segment requests to the appropriate resource—e.g.,a local content cache in the UE, or an external HTTP server, without aprotocol layering violation.

As can be seen in the examples of FIGS. 14A and 14B, each of the one ormore broadcast Representations is identified in the USD by a uniquebaseURL attribute of the broadcast element. The baseURL value may beidentical to a portion of the Segment URI used by the DASH client torequest a Segment of that Representation—specifically, the initialportion of the Segment URI starting from the method and extending to andinclusive of the RepresentationID. For example, if the Segment URI isthe URL “http://example.com/per-3/rep-512/seg-99.3gp,” corresponding toa request for Segment 99 of Representation 512 (RepresentationID=512) inPeriod 3, the baseURL may be defined as“http://example.com/per-3/rep-512”.

In this example, each of the one or more broadcast Representations isidentified in the USD by a unique baseURL attribute of the broadcastelement. Each instance of broadcast maps to a unique Representationdelivered over the MBMS bearer. Its baseURL will be compared to aportion of the Segment URI used by the DASH client to requestSegments—specifically, the initial portion of the Segment URI startingfrom the URI scheme and extending to and inclusive of theRepresentation-ID (value of Representation@id in the MPD). For example,assume the Segment URI issued by the DASH client is the URL“http://example.com/per-3/rep-512/seg-99.3gp”, corresponding to arequest for Segment 99 of Representation 512 (Representation@id=‘512’)in Period 3 (Period@id=‘3’). The portion of this URL of concern for thepurpose of matching with USD data is “http://example.com/per-3/rep-512.In the event that this Representation is also available over broadcast,an instance of mediaPresentationDescription2.broadcast will be presentin the USD with baseURL given by “http://example.com/per-3/rep-512”,identical to the portion interest in the request URI.

In the event the MBMS client determines that only alternativeRepresentation(s) to what is requested by the DASH client can beaccessed, the replacementAllowed attribute ofmediaPresentationDescription2 may indicate to the MBMS client whetherand how to provide such notification to the DASH client via the HTTPRedirect (3xx status code) method, e.g., as defined in RFC 2616.

For instance, if replacementAllowed=‘true’, it may be assumed that theDASH content and MPD are authored in such a way that allows the MBMSclient to provide, to the DASH client, alternative resource URI(s) via‘303 See Other’ redirection, regardless of the transport mode of thealternative Representation. Specifically, each alternative URI may beformed by replacing the portion of interest in the Segment URI asdescribed above with the baseURL in the USD corresponding to thealternative Representation, while retaining the Segment number in theoriginal request.

On the other hand, if replacementAllowed=‘false’, then such replacementmethod for generating an alternative resource URI and providing that tothe DASH client may not be allowed. The resulting technique for causingan alternative Representation to be requested and delivered may beimplementation dependent (e.g., the MBMS client may return a 4xx errorcode accompanied with the alternative Representation signaled by thebaseURL value, and rely on the DASH client to formulate an alternativerequest). An example call-flow showing interactions between the MBMSclient and the DASH client, based on HTTP ‘303’ redirection, isdescribed below with respect to FIGS. 15 and 16.

Similarly, each of the zero or more unicast Representations may beidentified in the USD by a unique baseURL attribute of themediaPresentationDescription2.unicast element. A matching pattern in thesame portion of the request URI, as discussed above, to the unicastbaseURL implies that this Representation is available over unicastdelivery. Note that the same Representation may be available over both,one-only, or neither of the transport modes.

Otherwise, via the sessionDescription element, each broadcastRepresentation may be linked to a Session Description fragment or SDPdocument pertaining to the FLUTE session carrying that Representation.In addition, the serviceArea element, if present, may denote the MBMSservice area(s) over which the broadcast Representation(s) areavailable.

FIG. 15 is a conceptual diagram illustrating an architecture forsupporting DASH over an MBMS. The example of FIG. 15 represents anend-to-end network architecture for DASH content delivery over MBMSbearer with unicast fallback. FLUTE-based download delivery representsthe TS 26.346-defined interface between the BM-SC and MBMS client. Theassumed interface between the DASH client and the MBMS client (hereassumed to be a composite entity including MBMS receiver, device-basedHTTP server, policy, redirection and proxy functions) is HTTP/1.1.

FIG. 16 is a flow diagram illustrating a call-flow associated with thenetwork architecture of FIG. 15 for DASH content delivery over broadcastand unicast transport. The techniques described with respect to FIG. 16are based on the USD extension shown in FIGS. 14A and 14B for carryingDASH transport information. Although described as corresponding to thenetwork architecture of FIG. 15, it should be understood that thetechniques of FIG. 16 may be performed by other devices, e.g., thedevices in the architectures of FIGS. 1, 2A, 2B, 6, 7, 8, and/or 17. Inthe example of FIG. 16, it is assumed that the USD contains theinformation shown in Table 3, which includes values of the baseURLattribute under mediaPresentationDescription2.broadcast andmediaPresentationDescription2.unicast, and it is assumed that the valueof the replacementAllowed attribute in the USD is “true.”

TABLE 3 mediaPresentationDescription2.- mediaPresentationDescription2.-broadcast unicast (baseURL) (baseURL) http://example.com/per-3/rep-512http://example.com/per-3/rep-256 http://example.com/per-3/rep-128

Furthermore, in this example, it is assumed that the MPD includes thefollowing contents:

-   -   MPD@type=‘dynamic’    -   Period@id=‘3’    -   Period.        SegmentTemplate@media=‘http://example.com/per-3/rep-$RepresentationID$/seg-$Number$0.3gp’        -   Representation@id=‘512’ . . .        -   Representation@id=‘256’ . . .        -   Representation@id=‘128’ . . .

Given these example MPD parameter values, the DASH client attempting torequest Segment no. 99 for Representation 512 in Period 3 may issue thefollowing request URI: http://example.com/per-3/rep-512/seg-99.3gp. Thecall flow of FIG. 16 describes DASH content delivery for two differentsituations: 1) UE is located in MBMS coverage, and requests Segments ofRepresentation 512 of Period 3, which is available over broadcastdelivery, and subsequently, 2) UE moves outside MBMS coverage, andcontinues to request the same Representation (i.e., Representation 512),which is not available over unicast delivery, but Representations 256and 128 are available over unicast.

In other words, this disclosure describes certain techniques for the useof USD-based signaling of DASH transport in support of transportdiversity. It may provide one or more improvements over a previousproposal described in Tdoc S4-130051, “Rationale for USD Indication ofDASH Delivery Mode and Illustrative Implementation” from Qualcomm Inc.For instance, a layering violation may be entirely avoided in thismethod, because the MBMS client does not have to understand or processMPD information. Instead, the MBMS client may perform data patternmatching of known transport semantics against the URIs of Segmentsrequested by the DASH client to determine whether the requested Segmentsare requested to be delivered via broadcast and/or unicast, and whetherthat request can be satisfied as is, or needs to be redirected to thesame or an alternate Representation available using another transportmode.

Such determination may be based on factors such as whether UE is locatedinside or outside of MBMS coverage, service provider policy, if any,governing accessibility of Representations by transport mode, andpossibly dependent on other conditions or rules. Example networkarchitecture and call flow diagram for DASH content delivery via MBMSwith unicast fallback were provided to illustrate end-to-end contentdelivery featuring the use of HTTP protocol interface between the DASHclient and MBMS client. The adherence to protocol layering shouldprovide architectural benefits in extensibility and simplicity of UEimplementation in support of DASH-in-MBMS services.

The use of HTTP Redirect via the 3xx status code by the MBMS client torestrict the DASH client access to an alternative resource(Representation) is predicated on the mediaPresentationDescription2'sreplacementAllowed attribute having the value ‘true’. In such event, itis assumed that the DASH content and MPD are authored in such a way thatallows the MBMS client to provide to the DASH client alternativeresource URI(s) via ‘303 See Other’ redirection, regardless of thetransport mode of the alternative Representation. Specifically, eachalternative URI is formed by replacing the portion of interest in theSegment URL as described above with the baseURL in the USD correspondingto the alternative Representation, while retaining the Segment number inthe original request. If the value of replacementAllowed=‘false’, thensuch replacement method for generating an alternative resource URI andproviding that to the DASH client is not allowed.

The resulting techniques to cause an alternative Representation to berequested and delivered may be implementation dependent. For example,the MBMS client may return an 4xx error code accompanied with or withoutan alternative Representation as signaled by the baseURL value in theentity body of the HTTP response, and rely on the DASH client to form analternative request. Here, the presence of the baseURL identifying analternative Representation is available in the response may be used as ahint to the DASH client with the intelligence to directly request thatRepresentation as follow-up. Alternatively, the baseURL “hint” may notbe provided in the 4xx response, or the DASH client may lack theintelligence to utilize such hint in generating a new request foranother Representation which may or may not correspond to the allowedRepresentation from the MBMS client perspective.

FIG. 17 is a conceptual diagram illustrating another examplearchitecture for supporting DASH over MBMS. It may be important tospecify the interface between BM-SC and eMBMS Client and the interfacebetween eMBMS Client and DASH Client in an appropriate standard. Forexample, the standard may specify that the interface between BM-SC andeMBMS Client shall comply with TS 26.346. The standard may also specifythat the interface between eMBMS Client and DASH Client should follow TS26.247 if DASH client and eMBMS client are from different vendors.Contrasted with the example of FIG. 16, FIG. 17 illustrates an examplein which an interface between a DASH client and an eMBMS client mayconform to TS 26.247 (which may be, for example, HTTP/1.1). FIG. 17illustrates a high level architecture to allow DASH over MBMS to be fallback to DASH over unicast.

FIGS. 18-23 are flow diagrams illustrating various example call-flowsassociated with the network architecture of FIG. 17 for DASH contentdelivery over broadcast and unicast transport. Although described ascorresponding to the network architecture of FIG. 17, it should beunderstood that the techniques of FIGS. 18-23 may be performed by otherdevices, e.g., the devices in the architectures of FIGS. 1, 2A, 2B, 6,7, 8, and/or 15.

With respect to the example of FIG. 18, USD signaling may include thedata shown in Table 4 below for the eMBMS Client:

TABLE 4 Broadcast@BaseURL Unicast@BaseURL http://www.cnn.com/512/http://www.cnn.com/256/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/128/seg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1=http://www.cnn.com/512/, RepresentationId=“512”;

Template=seg$Number$0.3 gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId=“256”;

Template=seg$Number$0.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId=“128”;

Template=seg$Number$0.3gp.

In the example of FIG. 18, it is assumed that the eMBMS client does nothave HTTP Proxy functions, but only has HTTP redirector functions.

With respect to the example of FIG. 19, USD signaling may include thedata shown in Table 5 below for the eMBMS Client:

TABLE 5 Broadcast@BaseURL Unicast@BaseURL http://www.cnn.com/512/http://www.cnn.com/256/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/128/seg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1=http://www.cnn.com/512/, RepresentationId=“512”;

Template=seg$Number$0.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId=“256”;

Template=seg$Number$0.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId=“128”;

Template=seg$Number$0.3gp.

In the example of FIG. 19, it is assumed that eMBMS client has both HTTPProxy and HTTP Redirector function.

With respect to the example of FIG. 20, USD signaling may include thedata shown in Table 6 below for the eMBMS Client:

TABLE 6 Broadcast@BaseURL Unicast@BaseURL http://www.cnn.com/512/http://www.cnn.com/512/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/256/seg$Number$.3pghttp://www.cnn.com/128/seg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1.1=http://www.cnn.com/512/,

BaseURL1.2=http://localhost/512/, RepresentationId=“512”;

Template=seg$Number$0.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId=“256”;

Template=seg$Number$0.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId=“128”;

Template=seg$Number$0.3gp.

In the example of FIG. 20, it is assumed that the eMBMS client does nothave HTTP Proxy function, but only has HTTP Redirector function.

With respect to the example of FIG. 21, USD signaling may include thedata shown in Table 7 below for the eMBMS Client:

TABLE 7 Broadcast@BaseURL Unicast@BaseURL http://www.cnn.com/512/http://www.cnn.com/512/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/256/seg$Number$.3pghttp://www.cnn.com/128/seg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1=http://www.cnn.com/;

RepresentationId=“512”; Template=$RepresentationId$/seg$Number$0.3 gp,RepresentationId=“256”; Template=$Representagtion$/seg$Number$0.3gp,RepresentationId=“128”; Template=$Representagtion$/seg$Number$0.3gp.

In the example of FIG. 21, it is assumed that eMBMS client does not haveHTTP Proxy function, but only has HTTP Redirector function.

With respect to the example of FIG. 22, USD signaling may include thedata shown in Table 8 below for the eMBMS Client:

TABLE 8 Broadcast@BaseURL Unicast@BaseURL http://localhost/512/http://www.cnn.com/256/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/128/seg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1=http://localhost/512/, RepresentationId=“512”;

Template=seg$Number$0.3gp,

BaseURL2=http://www.cnn.com/256/, RepresentationId=“256”;

Template=seg$Number$0.3gp,

BaseURL3=http://www.cnn.com/128/, RepresentationId=”“128”;

Template=seg$Number$0.3gp.

In the example of FIG. 22, it is assumed that eMBMS client does not haveHTTP Proxy function, but only has HTTP Redirector function.

With respect to the example of FIG. 23, USD signaling may include thedata shown in Table 9 below for the eMBMS Client:

TABLE 9 Broadcast@BaseURL Unicast@BaseURL http://www.cnn.com/1024/http://www.cnn.com/256/seg$Number$.3pg seg$Number$.3pghttp://www.cnn.com/512/ http://www.cnn.com/128/seg$Number$.3pgseg$Number$.3pg

The MPD in this example may specify the following data, where BaseURLscorrespond to base portions of URLs for accessing Segments:

BaseURL1=http://www.cnn.com/1024/, RepresentationId=“1024”;

Template=seg$Number$0.3gp,

BaseURL2=http://www.cnn.com/512/, RepresentationId=“512”;

Template=seg$Number$0.3gp,

BaseURL3=http://www.cnn.com/256/, RepresentationId=“256”;

Template=seg$Number$0.3gp,

BaseURL4=http://www.cnn.com/128/, RepresentationId=”“128”;

Template=seg$Number$0.3gp.

In the example of FIG. 23, it is assumed that eMBMS client does not haveHTTP Proxy function, but only has HTTP Redirector function.

FIG. 24 is a flowchart illustrating an example method for signaling datarelated to a time-shifted buffer (TSB) depth in accordance with thetechniques of this disclosure. For purposes of example, the method ofFIG. 25 is explained with respect to the components of FIG. 10, e.g.,MSDC 1010 and TSB 1212. However, it should be understood that thetechniques for utilizing a time-shifted buffer may be incorporated intoany of the various systems described herein, e.g., the systems of any ofFIGS. 1, 7, 8, 9, 12, 13, and/or 17.

Initially, MSDC 1010 may receive a session description protocol (SDP)message (2400). The SDP message may include an attribute that defines atime-shifted buffer (TSB) depth. Accordingly, MSDC 1010 may determine avalue for the attribute (also referred to as a TSB depth attribute) inthe SDP message (2402). The value of the TSB depth attribute may definethe depth of the TSB, e.g., in terms of seconds of playback for mediadata to be stored in the TSB. For example, the value of the attributemay define a maximum playback time, in seconds, that can be stored inthe TSB.

MSDC 1010 may therefore determine an amount of memory to be allocated toform the TSB from the signaled depth (2404). For example, assuming thatthe depth of the TSB is signaled in terms of seconds of playback formedia data, and assuming that a frame rate is signaled for video data,MSDC may determine a number of video frames to be stored in the TSB, asthe product of the frame rate (expressed in frames per second) and thenumber of seconds of media data to be stored. MSDC 1010 may thendetermine an amount of memory for the TSB based on the product of anaverage bitrate per frame and the number of frames. MSDC 1010 may usesimilar concepts for determining memory size for audio data, timed textdata, and the like.

MSDC 1010 may then allocate the determined amount of memory to form theTSB (2406). Thus, as MSDC 1010 receives media data, MSDC 1010 may storethe received media data in the TSB (2408). A playback application mayuse this buffered media data for time-shifted application, such as forwatching at a later time or for performing a trick mode, such as fastforward or rewind. Of course, the buffered data may also be used forsubstantially real time playback.

In this manner, the method of FIG. 24 represents an example of a methodincluding receiving a session description protocol (SDP) messageincluding an attribute that defines a time-shifted buffer (TSB) depth,determining an amount of memory for the TSB based on a value of theattribute, allocating the determined amount of memory to the TSB, andstoring at least a portion of media data associated with the SDP messagein the TSB.

Those of ordinary skill in the art will understand that information andsignals may be represented using any of a variety of differenttechnologies and techniques. For example, data, instructions, commands,information, signals, bits, symbols, and chips that may be referencedthroughout the above description may be represented by voltages,currents, electromagnetic waves, magnetic fields or particles, opticalfields or particles, or any combination thereof.

Those of ordinary skill will further appreciate that the variousillustrative logical blocks, modules, circuits, and algorithm stepsdescribed in connection with the disclosure herein may be implemented aselectronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, modules, circuits, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. Skilled artisans may implement the describedfunctionality in varying ways for each particular application, but suchimplementation decisions should not be interpreted as causing adeparture from the scope of the present disclosure.

In one or more examples, the functions described may be implemented inhardware, software, firmware, or any combination thereof. If implementedin software, the functions may be stored on or transmitted as one ormore instructions or code on a computer-readable medium and executed bya hardware-based processing unit. Computer-readable media may includecomputer-readable storage media, which corresponds to a tangible mediumsuch as data storage media, or communication media including any mediumthat facilitates transfer of a computer program from one place toanother, e.g., according to a communication protocol. In this manner,computer-readable media generally may correspond to (1) tangiblecomputer-readable storage media which is non-transitory or (2) acommunication medium such as a signal or carrier wave. Data storagemedia may be any available media that can be accessed by one or morecomputers or one or more processors to retrieve instructions, codeand/or data structures for implementation of the techniques described inthis disclosure. A computer program product may include acomputer-readable medium.

By way of example, and not limitation, such computer-readable storagemedia can comprise RAM, ROM, EEPROM, CD-ROM or other optical diskstorage, magnetic disk storage, or other magnetic storage devices, flashmemory, or any other medium that can be used to store desired programcode in the form of instructions or data structures and that can beaccessed by a computer. Also, any connection is properly termed acomputer-readable medium. For example, if instructions are transmittedfrom a website, server, or other remote source using a coaxial cable,fiber optic cable, twisted pair, digital subscriber line (DSL), orwireless technologies such as infrared, radio, and microwave, then thecoaxial cable, fiber optic cable, twisted pair, DSL, or wirelesstechnologies such as infrared, radio, and microwave are included in thedefinition of medium. It should be understood, however, thatcomputer-readable storage media and data storage media do not includeconnections, carrier waves, signals, or other transitory media, but areinstead directed to non-transitory, tangible storage media. Disk anddisc, as used herein, includes compact disc (CD), laser disc, opticaldisc, digital versatile disc (DVD), floppy disk and blu-ray disc wheredisks usually reproduce data magnetically, while discs reproduce dataoptically with lasers. Combinations of the above should also be includedwithin the scope of computer-readable media.

Instructions may be executed by one or more processors, such as one ormore digital signal processors (DSPs), general purpose microprocessors,application specific integrated circuits (ASICs), field programmablelogic arrays (FPGAs), or other equivalent integrated or discrete logiccircuitry. Accordingly, the term “processor,” as used herein may referto any of the foregoing structure or any other structure suitable forimplementation of the techniques described herein. In addition, in someaspects, the functionality described herein may be provided withindedicated hardware and/or software modules configured for encoding anddecoding, or incorporated in a combined codec. Also, the techniquescould be fully implemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide varietyof devices or apparatuses, including a wireless handset, an integratedcircuit (IC) or a set of ICs (e.g., a chip set). Various components,modules, or units are described in this disclosure to emphasizefunctional aspects of devices configured to perform the disclosedtechniques, but do not necessarily require realization by differenthardware units. Rather, as described above, various units may becombined in a codec hardware unit or provided by a collection ofinteroperative hardware units, including one or more processors asdescribed above, in conjunction with suitable software and/or firmware.

The detailed description set forth above, in connection with theappended drawings, is intended as a description of variousconfigurations and is not intended to represent the only configurationsin which the concepts described herein may be practiced. The detaileddescription includes specific details for the purpose of providing athorough understanding of the various concepts. However, it will beapparent to those skilled in the art that these concepts may bepracticed without these specific details. In some instances, well-knownstructures and components are shown in block diagram form in order toavoid obscuring such concepts.

Various examples have been described. These and other examples arewithin the scope of the following claims.

What is claimed is:
 1. A method of processing media data, the methodcomprising: receiving a session description protocol (SDP) messageincluding an attribute that defines a time-shifted buffer (TSB) depth;determining an amount of memory for the TSB based on a value of theattribute; allocating the determined amount of memory to the TSB; andstoring at least a portion of media data associated with the SDP messagein the TSB.
 2. The method of claim 1, wherein receiving comprisesreceiving the SDP message in accordance with one of real-time transportprotocol (RTP) and real-time streaming protocol (RTSP).
 3. The method ofclaim 1, wherein the attribute comprises an “a=tsb-length:” attribute.4. The method of claim 1, wherein the value of the attribute defines alength of the TSB.
 5. The method of claim 4, wherein the value for theattribute defines the length in terms of seconds of playback for mediadata stored in the TSB.
 6. The method of claim 1, wherein determiningthe amount of memory comprises determining the amount of memory based atleast in part on a frame rate for media data associated with the SDP. 7.The method of claim 1, further comprising extracting at least a portionof the stored media data from the TSB to perform trick mode playback. 8.The method of claim 7, wherein the trick mode comprises one of fastforward and rewind.
 9. The method of claim 1, wherein the SDP messagecomprises an SDP message for one of a broadcast SDP session and aunicast SDP session.
 10. The method of claim 1, wherein the SDP messagecomprises a unicast session description and a broadcast sessiondescription.
 11. The method of claim 10, wherein the SDP messageincludes attributes associated with identifiers of various sets of mediadata, wherein the attributes indicate whether the associated media datacorrespond to a broadcast media stream or a unicast media stream. 12.The method of claim 11, wherein the attributes comprise respective“a=group:” attributes.
 13. The method of claim 10, wherein the SDPmessage includes attributes that distinctly identify each media stream.14. The method of claim 13, wherein the attributes that distinctlyidentify each media stream comprise “a=mid:” identification tags, eachhaving unique identifier values.
 15. The method of claim 1, whereinallocating comprises allocating the determined amount of memory of amulticast services device client (MSDC) to the TSB.
 16. A device forprocessing media data, the device comprising one or more processorsconfigured to receive a session description protocol (SDP) messageincluding an attribute that defines a time-shifted buffer (TSB) depth,determine an amount of memory for the TSB based on a value of theattribute, allocate the determined amount of memory to the TSB, andstore at least a portion of media data associated with the SDP messagein the TSB.
 17. A computer-readable storage medium having stored thereoninstructions that, when executed, cause a processor to: receive asession description protocol (SDP) message including an attribute thatdefines a time-shifted buffer (TSB) depth; determine an amount of memoryfor the TSB based on a value of the attribute; allocate the determinedamount of memory to the TSB; and store at least a portion of media dataassociated with the SDP message in the TSB.